§ 1.1 Field of the Invention
The present invention concerns protecting traffic over communication networks and more specifically, using label switched paths (LSPs) to backup communication network connections.
§ 1.2 Background Information
The description of art in this section is not, and should not be interpreted to be, an admission that such art is prior art to the present invention. Communication networks, nodes and connections, as well as the need for connection failovers, are introduced in § 1.2.1. Then, known connection failover techniques and their shortcomings are introduced in § 1.2.2.
§ 1.2.1 Communication Networks and the Need for Connection Failovers
FIG. 1 illustrates an exemplary communications system 100. Communications system 100 includes a plurality of network nodes A-D 110, 120, 130, 140, and connections 105, 115, 125, 135 and 145. The network nodes (e.g., routers) may be located at remote geographic locations. The network nodes may include physical interfaces (e.g., ports) for receiving and transmitting data. The connections may include a communications link, an interface terminating the link at the source node, and an interface terminating the link at the destination node. The communications link may be any known communications medium such as copper wire, fiber optic cables, or wireless channels, for example.
A connection can fail. For example, one of the interfaces may fail, or the communications link may fail. When a connection failure occurs, most packet switching networks can determine a new route bypassing the failed connection. However, determining such a new route can take a relatively long time. During this time data packets may be lost. For some applications, such packet loss is unacceptable.
§ 1.2.2 Known Connection Backup Techniques and their Shortcomings
Mirroring connections and fast-reroute are known connection backup techniques. A mirror connection may provide a separate backup connection for backing up a primary connection. In communication system 100, for example, network node A 110 and network node B 120 can communicate data via a primary connection 105, as well as via a mirror connection 115. At each node, 110, 120, the mirror connection 115 has a different interface than that of the primary connection. Generally, the mirror connection 115 exhibits the identical configuration (e.g., in terms of IP addressing and Maximum Transmission Unit (MTU)) as the primary connection 105. When a connection failure occurs at the primary connection 105, data is automatically switched over to the mirror connection 115. Unfortunately this technique requires duplicate physical interfaces assigned at the source and destination nodes. Thus, mirroring is not attractive in terms of cost and scalability.
Fast-reroute can also be used. Fast-reroute uses failover resource reservation protocol (RSVP) LSPs. Fast-reroute establishes, between a pair of routers, a backup LSP for data packets that belong to a specific set of RSVP multi-protocol label switched (MPLS) sessions. When a connection failure occurs, data carried by specific RSVP MPLS sessions is forwarded to the next-hop node via the backup LSP. Since the original RSVP MPLS sessions already have a label, to perform the label switching when the data is monitored over to the backup LSP, the backup LSP can use the MPLS label stacking feature to forward the data.
Unfortunately the fast-reroute technique has a number of shortcomings. For an RSVP MPLS session to be qualified for this protection, it must encode the “local-protection-desired” flag in its RSVP Session Attribute Object (See the paper Awduche, et al., “RSVP-TE-Extensions to RSVP for LSP Tunnels”, Request for Comments 3209 (Internet Engineering Task Force, December 2001)) (incorporated herein by reference and referred to as “RFC 3209”.). Without this flag activated, an RSVP MPLS session will not be protected over a failed connection. The encoding of the flag can only be performed at the traffic-originating ingress node. Accordingly, fast-reroute lacks flexibility and granularity. A network operator may want to protect user traffic on a particular connection, regardless of traffic type or origin. Since the fast-reroute technique requires a flag to be set at the ingress node, it will only work for RSVP MPLS type traffic. A network operator would not be able to protect non RSVP MPLS type traffic. Further, if a particular ingress node is not equipped to set the required flag, data originating from that node cannot be protected.
In addition, network operators may want to protect user traffic based on their routing classification, such as internal traffic (e.g., managed via interior gateway protocol (IGP) such as Intermediate System-Intermediate System (IS-IS) and Open Shortest Path First (OSPF)), transit traffic (e.g., managed using inter-domain protocol such as border gateway protocol (BGP)), or tunnel virtual private network (VPN) traffic, where tunnels may be managed using not only RSVP, but by other MPLS protocols such as label distribution protocol (LDP). The fast-reroute technique is limited to RSVP MPLS sessions with a particular flag activated.
Therefore, it may be useful to provide a connection failover that overcomes these and other disadvantages.